U.S. Application No. 10/553,636 

Response to Final Office Action of January 7, 2008 

Pages 

REMARKS 

Applicant has carefully considered the official communication dated January 7, 2008. 
Applicant respectfully submits the following remarks are fully responsive to the official 
communication, and Applicant respectfully requests reconsideration of the final rejection. 

B. Rejection of Claims under 35 USC §103 

Claims 1-14 and 16-22 stand rejected under 35 U.S.C. §103 as being unpatentable over 
U.S. Patent No, 7,031,956 to Lee in view of U.S. Patent No. 6,470,343 to O'Brien et al. 
Applicant respectfully submits that its invention is patentable over these references, alone and in 
combination. 

Lee describes a mechanism for updating a relational database with supplemental data (see 
Abstract), which, in one example, involves adding data from an XML file into an existing 
database using a document type definition (DTD) (column 16, lines 17 to 20). To achieve this,* 
the DTD 18 is loaded by the system 10 and used in metadata format to generate not manage a . 
relational schema 22 (column 15, lines 49 to 52). Thus, data representative of the DTD is stored 
in metadata tables 34, before being used by the generator 28 to generate not manage a relational 
schema 22 (column 15, lines 62 to 67). 

The manner in which the schema is created is outlined in step 42 in Figure 2, and in 
further detail in Figures 6 to 8. This involves creating tables in the relational database, adding 
columns to the tables and then adding nesting relationships (column 17, lines 36 to 46), This 
allows the DTD 18 to be mapped to the relational schema 22 by mapping rules defining 
transformations over the metadata tables 34 (column 17, line 67 to colunm 18, line 3). Thus, the 
system uses the DTD of a specific XML file to generate metadata tables 34, which are in turn 
used to allow generation of the database schema 22, and corresponding mappings stored in the 
pattern mapping table 36. The mappings allow items from the XML file to be imported into the 
database using the loader 30. 

It should also be noted that the structure of the metadata tables 34 are inherently different 
to that of the database schema 22, as highlighted by the necessity for a mapping relationship. 
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The differences between the metadata tables and the relational database schema are further 
highlighted in the example tables in column 30, line 20 through to column 32, which show how 
the relational database schema 22 has a completely different structure to the metadata tables. 
Consequently, even if the metadata tables had a similar structure to the claimed database schema, 
if a skilled person were to attempt to define a database schema based on the metadata tables of 
Lee, this would still not lead to the claimed database schema. 

The claimed invention relates to a database management system that includes a database 
schema. Claim 1 is directed towards a database schema, which corresponds in general terms to 
the database schema 22 of Lee, However, in Lee, the metadata tables are used as a basis to allow 
the relational schema 22 to be generated, and for this reason alone a skilled person would not 
look to the metadata tables of Lee for the database schema management of the present invention, 
because the metadata tables of Lee are not a database schema. 

Applicant also respectfully submits there is a fundamental difference in the purpose of 
system of Lee and the claimed invention. Lee is intmded to allow data fi"om an XML file to be 
imported into a relational database. As each relational database can have a different schema, and 
.as each XML file may have a different DTD, Lee attempts to address this by providing a loading 
system that can be customised for each database and XML file combination. 

To achieve this, the system operates by generating metadata tables based on the specific 
DTD of the XML file. In addition, as the relational database schema in tum depends on the 
metadata tables, then this will also vary, depending on both the original schema used and the 
DTD. Consequently, the database schema will require updating each time an XML file having a 
different DTD is imported into the database. Hence, Lee describes a system that attempts to 
overcome issues with importing data into a database, by generating custom metadata tables based 
on a DTD, and then customising a relational database schema to allow data importing. 

The present invention is distinct from Lee in that it relates to a database management 
system utilising a specific database schema. For example, in Lee the metadata tables generated 
will vary depending on the nature of the DTD. The metadata tables are therefore transient in the 
sense that they exist only when it is required to import the XML file. Once this is completed, the 
metadata tables can be deleted, with access to the data in the database being achieved utilising 
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the database schema, and with new metadata tables being generated when an XML having a 
different DTD is to be imported. 

In contrast, persons skilled in the art understand that database schemas are required to 
persist, thereby allowing database structure to be interpreted, and hence to allow data to be 
retrieved. For this reason, the skilled person would dismiss the metadata tables of Lee as being 
irrelevant to the claimed invention. 

In addition to this, as described on page 1 of the current specification, the use of custom 
schemas results in significant problems. First, new schemas must be generated for each 
application. Second, updating the schema is a complex and time consuming procedure. For 
example, updating the schema to reflect a new entity requires adding of a new entity table to the 
schema and inter-relating the new table to existing tables and possibly to other new tables. As a 
result, using the techniques of Lee, a user incurs significant overheads in maintaining the 
database schema. Accordingly, for this reason, a skilled person would also recognise that 
problems exist with utilisation of the technique of Lee. 

In contrast to this, current claim 1 relates to a database management system having a 
.defined database schema. The database schema provides a generalised configuration that can be 
applied to all relational databases, avoiding the need to configure a specific schema for each 
different application, as well as allowing use in a wider variety of scenarios than can be achieved 
using custom schemas, as proposed by Lee. 

In particular, the system provides a database schema where new entity types, instances of 
those entities, their attribute fields and data in respect of the attribute fields may all be added 
without having to create new tables. Instead, a new type of entity may be stored in the first table 
of claim 1, while the second table can be used to store the names of entities that are instances of 
the various entity types provided in the first table. A third table is also used to store the names of 
fields in respect of the various entity types. Thus, the database management system of claim 1 
provides a schema that can be updated to define new entity types, without the need for new tables 
in the schema, in contrast to the process used by Lee. Therefore, Applicant respectfiilly submits 
his invention is not obvious in view of Lee. 

Applicant will now address specific objections in fiirther detail. 
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Initially, the Examiner asserted that the claim requirement for a "first table" is met by the 
element 30 of Figure IB. Element 30 corresponds to a loader, which is described as being used 
to "create and fill the tables 20. . . according to the generated table schema" (column 16, lines 55 
to 57). The requirement for the loader 30 to use the database schema means that the loader 
cannot form part of the database schema itself, as required by claim 1 . Applicant respectfully 
submits that the loader 30 is a separate element to the metadata tables. Consequently, even in the 
event that the Examiner is interpreting the metadata tables of Lee as providing a database 
schema, the loader 30 cannot be part of a database schema as it does not form part of the 
metadata tables. Hence, the tables of the loader 30 cannot meet the requirement for a "first table" 
which forms part of a database schema as defined in claim 1 . 

Second, the Examiner indicates that the "second table" of claim 1 corresponds to 
elements 90 and 96 of Figure IB of Lee. However, elements 90 and 96 are specifically metadata 
tables 30 and the optimised metadata tables 36, respectively. As previously discussed, these are 
used in generating a database schema, but do not form part of the schema itself Applicant, 
therefore, does not believe these tables represent a second table within a database schema as 
vTcquired by claim 1 . Even if this is not the case, the elements 90 to 96 are part of the metadata 
tables and as such cannot be related to the first table, which is not part of the metadata tables, but 
rather is a loader. 

The Examiner also indicates that the "third table" required by claim 1 is shown by virtue 
of the step of forming tables of each element type. First, Applicant respectfully submits that this 
highlights distinctions between the claimed invention and the art, as this step explicitly requires 
forming the database schema, highlighting that the database schema is different to the metadata 
tables, thereby supporting the conclusion above that the elements 90 and 96 do not form part of a 
database schema. Second, in the event that the step is followed, a respective table is generated 
for each element type in the metadata item table. Thus, this would require multiple tables, one 
table for each element type, and would not lead to a "third table to store the names of fields in 
respect of the various entity types." 

Applicant also respectfiilly submits that O'Brien does not teach or suggest overcoming 
the deficiencies of Lee to lead to the claimed invention. O'Brien describes a schema containing 
tables enabling various parties to define extensions to a core data model (column 3, lines 2-5). 
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For example, Figure 3 of O'Brien and the accompanying descriptive text discloses a number of 
tables that are used for extending the data that may be stored in relation to a core table. 
However, it does not describe a database management system that has a schema that allows new 
entity types to be added to the core data model by means of generic entity type and entity tables, 
without requiring the addition of new tables. Applicant also notes that O'Brien also does not 
disclose a first table to store the names of various entity types, a second table related to the first 
table to store the names of instances of entities of the various entity types and further tables to 
store field attributes and field data, as required by claim 1. Consequently, the teaching of Lee, 
even when considered in the light of O'Brien, does not lead a skilled person to the teaching of 
claim 1, claim 18, or their respective dependent claims. Applicant respectfully submits that 
claims 1-14 and 16-22 are patentable over Lee in view of O' Brian. 

Claim 15 stands rejected under 35 U.S.C. 103(a) as being unpatentable over Lee and 
O'Brien and further in view of U.S. Patent Application Publication No. US2003/0 167455 to 
Iborra et al. Applicant submits that claim 15 is patentable over the combination of these 
references. 

Claim 1 5 depends from claim 1 and includes all of its limitation. For the reasons given 
above, that Lee and O'Brien do not disclose any details of the database management schema of 
the present invention, the addition of Iborra does not overcome the deficiencies noted in Lee and 
O'Brien. Therefore, claim 15 is patentable over the combination of references. 
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It is respectfully submitted that all of the Examiner's objections have been successfiiUy 
traversed. Accordingly, it is submitted that the application is now in condition for allowance. 
Reconsideration and allowance of the application are courteously solicited. 
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